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NETWORK SECURITY ARCHITECTURE SYSTEM UTILIZING SEALS 



Daniel F. Zucker 



FIELD OF THE INVENTION 

This invention relates to secure communications 
and in particular to systems and methods for multicast 
key management . 



10 BACKGROUND OF THE INVENTION 

Broadcast or multicast is the transmission of data 
from a single sender to multiple recipients, with 
broadcast transmission being a "one-to-all" 
transmission and multicast transmission being a "one- 

15 to-many" transmission. In this application, 
"multicast" and "broadcast" will be used 
interchangeably . 

FIG. 1 shows a typical multicast system 110 using 
conventional cryptography which is oriented toward 

20 point to point encryption. In a multicast system which 
uses point to point encryption, if party A wants to 
send data to parties B, C and D, party A must somehow 
communicate a secret key individually to each of the 
parties B, C and D such that no one else knows the key. 

25 In the Public Key Infrastructure (PKI) 

cryptography, party A uses a common symmetric key K for 
all three transmissions, but sends this common 
symmetric key K three different times encrypted 
individually for each of the parties B, C and D. To do 

30 this encryption, party A makes use of first, second, 

and third keys, each different, for parties B, C and D, 
respectively. Each such key is called a "public key." 
The public key is part of the public/private key pair 
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that has been previously established using conventional 
methods. For example, party A uses the public key for 
party B to encrypt a random common symmetric key K and 
then sends the encrypted common symmetric key 10 0 so 
5 encrypted to party B. Party A then uses the public 
keys for parties C and D to encrypt the random common 
symmetric key K to form encrypted common symmetric keys 
102 and 104, respectively, and sends the encrypted 
common symmetric keys 102 and 104 to parties C and D, 
10 respectively. Party A then encrypts a message using 
the random common symmetric key K and broadcasts the 
encrypted message to all listeners. Parties B, C and D 
can now use their respective private keys to decrypt 
the encrypted common symmetric key K and then use the 
15 decrypted common symmetric key K to decrypt the 
broadcast message . 

Alternatively, party A broadcasts the encrypted 
broadcast message 202 and the encrypted common 
symmetric keys 204 for each intended recipient, i.e., 

20 encrypted common symmetric keys 100, 102, and 104, to 
all listeners B, C and D, as shown in FIG. 2, A 
listener, for example, party B, then either tries to 
decrypt all the encrypted common symmetric keys using 
his private key, looking for the encrypted common 

25 symmetric key specifically encrypted for him, or, he 
looks for his name followed by an encrypted common 
symmetric key if party A does not care about public 
knowledge of "who gets what message." Party B can then 
use the decrypted common symmetric key K to decrypt the 

30 broadcast message . An unintended recipient cannot find 
an encrypted common symmetric key that is encrypted for 
him, and thus is unable to decrypt the broadcast 
message . 

The point to point encryption approach to 
35 multicast described above is sufficient if the 
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recipients are few. However, the point to point 
encryption approach becomes difficult to manage as the 
number of the recipients increases. For example, if 
there are 10,000 recipients instead of three, party A 
would need to encrypt the single random symmetric key K 
10,000 times using 10,000 public keys. As a result, 
key management, which involves the selection, 
distribution and maintenance of the encryption keys, 
and security becomes difficult and impractical. 

Therefore, what is needed is an efficient 
multicast key management system. 



SUMMARY OF THE INVENTION 

In accordance with the present invention, a method 
for efficient multicast key management is provided. 
The security server establishes a private access line 
("PAL") which provides client I.D. and authentication 
between a client and the security server. The system 
allows the transmission of what are called "permits" 
and "seals" to allow the storage of secured documents 
and the accessing of secured documents by authorized 
clients or for secured messaging between clients. 

As part of the security associated with the 
security server, the security server generates what is 
called a "seal." In one embodiment, the seal contains 
a key. In another embodiment, the seal contains the 
information to generate a key. The security server 
encodes this key or information to generate this key 
using any encryption method. The encoded key is called 
a "seal" which is generated by the security server. In 
one embodiment, the seal contains additional 
information, such as a user identification code, a 
policy which is a description as to who is allowed 
access to what (e.g., classification of files and 
security levels of clients) , a message digest which is 
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a hash of files (i.e., containing a "fingerprint" of a 
data stream), and a date/time stamp. The key or the 
information to generate the key is often called a 
'''permit," so the permit is contained within the seal • 
5 but may not be the exclusive contents of the seal. All 
the information contained in a seal is encrypted by the 
security server and can only be "opened," i.e., 
decrypted, by the security server which encrypted the 
seal . 

10 In accordance with this invention, the security 

server generates seals and permits. These seals and 
permits are communicated between the security server 
and a security client. The security client may be, for 
example, an application server or an application 

15 client. The application server and application client 
pair can be a web server and web client pair, a lotus 
notes server and lotus notes client pair or a database 
server and database client pair. The application 
server first sends a request to the security server 

20 requesting a seal for a particular communication. The 
security server returns a seal to the application 
server which then broadcasts the seal to a plurality of 
application clients. Each client wishing to encrypt or 
decrypt a data stream sends the seal it received from 

25 the application server to the security server in an 
open seal request signal, together with the client's 
identification information, so that the seal can be 
"opened." The security server, upon receiving the open 
seal request signal, decrypts the seal and compares the 

30 client's identification with the policy stored at the 
security server. If the client's identification 
matches the policy, the security server extracts a 
permit from the decrypted seal and transmits the permit 
to the client in clear text form. In one embodiment, 

35 the client then uses the permit to generate an 

encryption/decryption key for encrypting a data stream 
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or decrypting an encrypted data stream. If the client 
is a sender, he broadcasts the encrypted data stream 
together with the seal to all the listeners, regardless 
of the identity or the number of recipients because an 
unauthorized recipient will not be sent a permit from 
the security server. 

In one embodiment, the same seal is sent 
periodically in an encrypted data stream. An offset 
value indicating an offset with respect to the 
beginning of an encrypted message is sent with each 
seal to enable the recipient to determine the portion 
of the data stream from where the decryption begins. 
This allows decryption of at least a portion of an 
encrypted data stream that is received partially. 

In another embodiment of the invention, a copy of 
a seal that has been "opened" and its corresponding 
permit are cached and stored locally in the memory of 
the security client, the memory being denoted as a 
local seal cache. The next time a seal needs to be 
opened at the security client, the seal is first 
compared to all the seals stored in the local seal 
cache by, e.g., a byte-f or-byte value comparison. If a 
match is found, a permit corresponding to the matched 
seal is returned from the local seal cache. 
Conversely, if there is no match, a request-to-open- 
seal signal is sent to the security server to open the 
seal. If it has been established that the security 
client's identification matches the policy, the seal is 
opened. The newly opened seal and its corresponding 
permit are then stored in the local seal cache. When 
the local seal cache exceeds its capacity, the least 
recently used seal and permit pair is deleted from the 
local seal cache before the most recently opened seal 
and permit pair is stored. 

In yet another embodiment of the invention, a seal 
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is attached to every individual datagram packet in a 
UDP (User Datagram Protocol) system so that the order 
in which the packets are received does not have any 
significance because each packet is encrypted/decrypted 
individually. Similarly, a lost datagram packet does 
not affect the integrity of the encryption (although it 
might affect the integrity of the received data unless 
the data is resent.) In this embodiment, the server 
and the client do not need to negotiate a symmetric 
session key and an encryption algorithm upon each 
session initiation because every packet has its own 
seal and can be decrypted individually and 
independently from the other packets. 

In another embodiment of the invention, a separate 
seal is appended to the head of any data stream, 
allowing full duplex communication. When the data with 
appended seal is received, the recipient sends the seal 
to the security server to be opened and uses the 
resulting permit received from the security server to 
decrypt the encrypted data. No synchronization or 
handshake protocol between the two duplex channels is 
required since the data sent in each direction has its 
own corresponding seal . 

This invention will be more fully understood in 
light of the following detailed description taken 
together with the following drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 (prior art) shows a multicast system 
utilizing point to point cryptography; 

FIG. 2 (prior art) shows an embodiment of a 
multicast system utilizing point to point cryptography; 

FIG. 3A shows communication between a security 
server, an application server and a client; 
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FIG. 3B shows a multicast system in accordance 
with one embodiment of the present invention, wherein 
the same data stream is sent to all the recipients; 

FIG. 4 shows an embodiment where the same seal is 
sent periodically in the data stream, each seal having 
a corresponding offset value; 

FIG. 5 shows a flow chart illustrating a method 
for opening multiple instances of identical seals; 

FIG. 6 illustrates key synchronization over an 
unreliable transport by appending a seal to each 
datagram packet ; and 

FIG. 7 illustrates key exchange and 
synchronization over a duplex channel by appending a 
seal to the head of each data stream. 

The use of the same reference symbols in different 
drawings indicates similar or identical items. 

DETAILED DESCRIPTION 

The following description is meant to be 
illustrative only and not limiting. Other embodiments 
of this invention will be obvious in view of the 
following description to those skilled in the 
encryption arts. 

FIG. 3A and 3B illustrate a multicast system in 
accordance with the present invention. FIG. 3A shows a 
communication infrastructure using a security server 
303 called TESS (TriStrata Enterprise Security Server) 
developed by TriStrata Security Inc. Security server 
303 allows the transmission of what are called "seals" 
and "permits" to allow the storage of secured documents 
and the accessing of secured documents by authorized 
clients or for secured messaging between clients. The 
permit is essentially a key. The seal contains the 
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encrypted permit and in some embodiments, additional 
client information. Seals and permits are described in 
detail below. 

In one embodiment, secure communication between 
security server 303 and an application server 306 and 
communication between security server 3 03 and an 
application client 307 are accomplished by establishing 
a private access line (PAL) between security server 3 03 
and application server 306 and a private access line 
between security server 303 and application client 307, 
respectively. Application server 306 is, for example, 
a web server, lotus notes server or database server. 
Application client 3 07 is, for example, a web client, a 
lotus notes client or a database client. It is noted 
that both application server 306 and application client 
307 are security clients of security server 303. 

In general, all secure communications between a 
client machine and a server machine (e.g., between an 
application server and an application client) are 
intercepted at the transmission control 

protocol/internet protocol sockets level and passed to 
the virtual private network machine for processing. 

In one embodiment, the private access line is 
established by using a pointer exchange process 
described in U.S. Patent Application Serial No. 
08/552,029 (hereinafter, the ^029 application), filed 
November 2, 1995 and assigned to the same assignee as 
the present application, herein incorporated by 
reference in its entirety. 

In the ^029 application, systems and methods are 
provided which allow a working key (i.e. the key used 
to encrypt a data stream) to be used only once and then 
changed in a manner which is essentially random, fast 
and unique to each client. In accordance with the 
invention disclosed in the "029 application, a client 
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accessing a network computer is issued a randomly 
selected bit stream of a given length. This bit 
stream, called the "master signature," is divided into 
bytes, and each byte is assigned a unique byte address. 
When this byte is addressed, the bits associated with 
this byte can be read out. In one embodiment of the 
'029 application, a split signature, asymmetric mode 
technique is used to secure communications between a 
computer and client. From the computer's "master 
signature," a portion, called the "access signature," 
is selected and placed at the client. The computer, 
which could be at a bank or any service provider, 
retains the corresponding addresses filed under the 
client's I.D. This access signature includes both the 
bit information in the bytes selected from the master 
signature as well as the addresses of those bytes in 
the master signature. To securely communicate between 
a bank and a client, each selects a random set of 
addresses from the client's access signature. These 
independent sets of addresses are exchanged between 
sides. Each side, the bank and the client, now having 
both sets of addresses, obtains the corresponding bits 
which determine a unique session signature. Of 
importance, the particular bytes making up the session 
signature are never transmitted between the bank 
computer and the client. All that is transmitted are 
the addresses of the bytes making up the session 
signature. Both the client's terminal and the bank's 
computer have the identical session signature (also 
called the "session key") . 

One way to transmit the seals is discussed in U.S. 
Patent Application Serial No. 08/749,946 (hereinafter 
the '946 application), filed November 5, 1996 which is 
assigned to the same assignee as this application and 
is herein incorporated by reference in its entirety. 
The '946 application discloses an improvement on the 
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'029 application wherein the session signature (i.e. 
key) is uniquely generated from a segment of the access 
signature by identifying the address of the initial 
byte in the session signature and the length of the 
session signature (i.e. the number of bytes or bits in 
the session signature) using a pointer. As a result, 
the number of bits required to transmit the addresses 
of bytes in the session signature is reduced 
substantially. The pointer defines both the address of 
the initial byte in the session signature and the 
number of bytes in the session signature. If desired, 
the session signature can be of a predefined length, or 
the session signature can be as long as the maximum 
length message, rendering unnecessary the bits in the 
pointer defining the length of the session signature. 

In one embodiment of the '94 6 application, a 
master signature is divided into two subsets of bytes 
and each subset is stored in a separate compartment. 
These two compartments, known as the "shared key 
buckets," are available to and shared with all clients 
authorized to use the bytes in the shared key buckets 
for encrypting information. Another two compartments 
of bytes called the "DES-keys buckets" reside securely 
only in the security server. The client accesses the 
security server and uses the pointer exchange process 
to establish a private access line which provides 
identification and authentication between the client 
and the security server. The security server issues to 
the client a permit which is a pair of pointers PI, P2 
randomly selected from the two compartments of the 
shared key bucket. These pointers PI, P2 are 
transmitted to the client over the previously 
established PAL. 

The client having received PI , P2 and having the 
shared key bucket thereby is able to determine the 
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encryption key. The client then uses the encryption 
key so derived to encrypt the document to be stored in 
memory somewhere in the system. The server also 
derives two DES-keys from the DES-key bucket. These two 
DES-keys are determined by two separate pointers pi, 
p2, independent of pointers PI, P2 used to derive the 
session signature from the shared key bucket. A 
derived DES-key is obtained by exclusively ORing the 
two DES-keys. The DES-key so derived is used to 
encrypt PI, P2 to provide a seal. The document, 
encrypted by the encryption key (i.e. the session 
signature) at the client, is then stored in memory in 
the system along with PI, P2 encrypted at the server by 
the DES-key to provide a seal, and the DES-key pointers 
pi and p2 . 

The procedure which is followed for an authorized 
client to decrypt a document so secured is to: 

1. pull the encrypted document, seal and pi, p2 
from memory; 

2. establish a PAL between the client and the 
security server; 

3 . transmit the seal and DES pointers from 
storage to the security server; 

4. security server unlocks seal and transmits 
pointers PI, P2 to the client (the seal besides 
including Pi, P2 can also include other data such as 
the time stamp and the client I.D.); and 

5. client decrypts the document using pointers 
PI, P2. 

Another U.S. Patent Application Serial No. 
09/095,350 (hereinafter the *350 application), filed 
June 9, 1998 which is assigned to the same assignee as 
this application, discloses a further improvement for 
the security architecture system described above and is 
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herein incorporated by reference in its entirety. The 
improved security architecture system utilizes pointers 
and employs a method for generating encryption bits 
from a set of bits in such a manner as to avoid 
redundancy and to obtain a large number of encryption 
bits from the given set of bits. In one embodiment, 
the pointer is made up of eight bits and the session 
signature to be identified by the address contained in 
the pointer is of a predefined length. Accordingly, no 
bits are required in the pointer to define the length 
(i.e. the number of bytes) in the session signature. 
All that is required is the address of the first byte 
in the session signature. Importantly, the string of 
bits defining the pointer includes one additional bit. 
Accordingly, additional pointers can be generated from 
this string of bits by shifting this string of bits one 
space and generating a new pointer from the shifted bit 
string. Repeating this shifting a number of times 
equal to the number of bits in the string yields an 
additional number of pointers equal to the number of 
bits in the string. When the original bit string is 
obtained, the string of bits is discarded to avoid 
defining a session signature already used. A second 
string of bits comprising a pointer plus one extra bit 
is then sent to the client from the central computer 
and used to again define additional session signatures. 

In general, security server 303 generates a seal 
which contains encrypted information such as, but not 
limited to, permit, policy, message digest and 
date/time stamp. It is noted that the entire content 
of the seal is encrypted at security server 303 using 
any encryption method or standard, such as Data 
Encryption Standard (DBS) and triple DES. The seal can 
only be "opened" by security server 303, and cannot be 
interpreted unless security server 3 03 opens it. The 
seal open process is discussed in detail later. 
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The permit is a set of bits containing information 
relating to an encrypt ion/decrypt ion key. For example, 
the permit may contain pointers that are used to 
generate the encryption/decryption keys, as discussed 
5 in the '029, '946, and '350 applications, incorporated 
by reference above. The permit may also contain the 
encrypt ion/decrypt ion key itself. The policy contains 
description as to who is allowed access to what, for 
example, the policy may contain classification of files 
10 or security levels for a client. The message digest is 
a hash of files, meaning that it contains a 
"fingerprint" of a data stream. 

Referring to FIG. 3A, application server 306 first 
sends a seal request signal to security server 3 03 via 

15 a private access line 3 05, requesting a seal. Security 
server 303 sends a seal to application server 306 via 
private access line 318. Application server 3 06, after 
receiving the seal, sends the seal to application 
client 307 via communication line 313. Application 

20 client 307 receives the seal and sends a request-to- 
open-seal signal to security server 303 via private 
access line 312. Security server 303 verifies the 
status of application client 3 07 and sends a permit 
back to application client 307 via private access line 

25 314. If the permit is an encryption/decryption key, 
the permit is used to encrypt /decrypt a message. If 
the permit contains information of an 
encryption/decryption key but not the key itself, 
application client 307 first generates an 

30 encryption/decryption key from the permit. Application 
client 307 then uses the generated 

encryption/decryption key to encrypt /decrypt a message. 

In a multi-user system, the application server, 
e.g., party A, in one embodiment, broadcasts the seal 
35 to a plurality of application clients, e.g., parties B, 
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C and D. When party A, e.g., application server 306, 
desires to encrypt a data stream, party A sends a 
request-for-seal signal 312, together with party A' s 
identification to security server 3 03. Security server 
303 compares the requested policy against party A' s 
identification and policy to determine if party A is 
authorized to receive the seal. If security server 303 
determines that party A is an authorized client, 
security server 303 returns a permit in clear text form 
with the requested seal via private access line 318 to 
party A. In one embodiment, as shown in FIG. 3B, for 
example, party A generates an encryption key (or 
session key) from the permit in a manner such as 
described in the above referenced patent applications. 
Party A then uses the encryption key to encrypt a data 
stream. Next, party A broadcasts the encrypted data 
stream 302 with an appended seal 304 to, e.g., parties 
B, C and D via communication lines 315, 316 and 317, 
respectively. 

Parties B, C and D receive the same encrypted data 
stream and seal from party A. Each party B, C and D 
then individually sends the received seal 3 04 to the 
security server (not shown) to establish a PAL between 
each party B, C and D and the security server. As 
discussed above, only an authorized client receives a 
permit from the security server. For example, if party 
B is authorized, party B receives a permit from the 
security server. Party B can then use the permit to 
generate a decryption key that is the same as the 
encryption key generated by party A. Party B can then 
use the decryption key to decrypt the encrypted data 
stream. On the other hand, if party C is unauthorized, 
the security server does not return a permit to party 
C, and party C cannot generate the decryption key for 
decrypting the encrypted data stream. Similarly, 
parties B, C and D can generate encrypted data streams 
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in the same manner as described for party A and 
broadcast the encrypted data streams to other parties. 

By sending a seal instead of an asymmetric key 
pair, party A broadcasts the same encrypted data stream 
5 to all the recipients regardless of the identity or the 
number of the recipients. Unauthorized recipients are 
not allowed to open the seal at the security server, 
and without the appropriate permit, unauthorized 
recipients are unable to decrypt the encrypted data 
10 stream broadcast by party A. 

The method described above solves the broadcast 
key distribution problem. However, the method works 
only if all the recipients receive the data stream from 
the beginning because the recipients who begin to 

15 receive the data in midstream cannot decipher the data 
stream since the seal is sent only once at the 
beginning of the data stream. To solve the problem 
caused by recipients receiving data from midstream, in 
accordance with this invention, the same seal is sent 

20 periodically in the data stream. 

FIG. 4 illustrates a method for efficient 
synchronization of keys for streaming media such that a 
recipient can begin decrypting the encrypted stream at 
selected points in the stream. Streaming media is 

25 typically employed for large multimedia files, where a 
client downloads a portion of a file, decompresses that 
portion and starts playing the contents, e.g., 
audio/video, before the rest of the file arrives. 
Subsequent portions of the multimedia file are 

30 downloaded while the previously downloaded portion is 
playing. 

In accordance with this invention, data stream 400 
is divided into data sections 401 through 404. Each 
data section 401 through 404 has a corresponding seal 
35 and a corresponding offset value indicating the offset 
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with respect to the starting point of data stream 400, 
appended to the head of the data section. The offset 
values enable the recipients to determine where in data 
stream 400 the decryption begins so that at least a 
portion of data stream 400 can be decrypted. This is 
opposed to the method where the seal is only sent once 
at the beginning of the message, in which case if the 
beginning of the message is missing, the entire message 
cannot be decrypted. In an embodiment where the 
message is re-sent or sent more than once, sending 
seals periodically along with an offset value prevents 
the same portion of data stream 4 00 to be reused, i.e. 
decrypted more than once . 

FIG. 5 is a flow chart illustrating an embodiment 
of the present invention, in which seals that have been 
opened previously are cached and stored in a local seal 
cache at the security client (e.g., application server 
and application client) so that multiple copies of the 
same seal do not have to be opened at the security 
server each and every time a seal is received by a 
security client. When the same seal is broadcast at 
various times, for example, when a seal is sent 
periodically in the data stream, as that described in 
conjunction with FIG. 4, a recipient may receive 
multiple copies of the same seal. One method is to 
open the seal at the security server each and every 
time a seal is received by a security client. However, 
opening the seal at the security server every time a 
seal is received uses an unnecessary number of 
transactions to the security server if the same seal is 
received by a security client multiple times. To 
operate the system more efficiently, the same seal can 
be used multiple times but only opened once, by caching 
the seals that were opened previously. 

In step 500, the sender broadcasts a seal to a 
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number of recipients. Each recipient compares the 
received seal with the seals that have been previously 
opened and stored in a local seal cache at the 
recipient (step 504) . The local seal cache stores 
5 seals that have been opened and also their 

corresponding permits. In other words, the local seal 
cache contains seal/permit pairs. The local seal cache 
can be of any memory size, depending on the size of the 
seal/permit and the number of seal /permit pairs the 

10 user would like to store. The received seal is 

compared using, e.g., a byte-f or-byte value comparison 
method. If the received seal matches one of the seals 
stored in the local seal cache {step 506) , a 
corresponding permit is returned from the local seal 

15 cache to the recipient (step 508) . However, if the 

received seal does not match any of the seals stored in 
the local cache, the seal is sent to the seal open 
routine at the security server (step 510) . The 
security server decrypts the seal and compares the 

20 recipient's identity against the policy to determine 

whether the recipient is authorized (step 512) . If the 
recipient is not properly authorized (step 512) , the 
procedure returns to the beginning to await for another 
seal to be sent from a sender. 

25 On the other hand, a permit is extracted from the 

seal if the recipient is properly authorized (step 
514) . A newly opened seal and its corresponding permit 
are stored in the local seal cache (step 520) if it has 
been determined that the seal cache is not full in step 

30 516. If the seal cache is determined to be full (step 
516) , a least recently used seal and permit pair is 
deleted from the seal cache (step 518) before the newly 
opened seal and its corresponding permit are stored in 
the local seal cache (step 520) . The permit is then 

35 returned from the seal cache to the recipient (step 

508) . By using a local seal cache, the system operates 



-17- 



M-7190 US 
478096 v2 



more efficiently because the same seal does not need to 
be opened multiple times by the security server. 

FIG. 6 shows a seal appended to each data packet 
for a datagram communication. The majority of network 
5 security protocols gear toward connection-oriented 

protocols, e.g., transmission control protocol ("TCP"), 
because of the unreliable mechanism associated with 
internet protocol ("IP") for transferring data between 
two computers. TCP/IP provides a reliable stream of 

10 data that is in the exact sequence generated by the 

source. TCP/IP accomplishes this by breaking the data 
stream into packets small enough to fit inside IP 
datagrams which are numbered and sent using an 
acknowledgment-with-retransmission paradigm, meaning 

15 that the receiver sends an explicit or implicit 

acknowledgment for each IP datagram. The sender waits 
for some time and then retransmits the IP datagram if 
it does not receive an acknowledgment. In this scheme, 
the source port and the destination port must be 

20 identified prior to transmission of a data stream. 

The minority few cater to datagram communication 
such as User Datagram Protocol (UDP) . UDP is a 
connectionless datagram protocol and has certain 
advantages over a connection-oriented protocol such as 

25 TCP/IP. For example, in a datagram communication, 
every packet of data is sent individually from the 
' source to the destination. No connection, e.g., 
handshaking mechanism, is required for sending a 
datagram packet. However, the UDP protocol is 

30 unreliable because there is no guarantee that a sent 
packet will arrive at its destination. There is also 
no guarantee that packets will be received in the same 
order they are sent. Therefore, UDP encryption either 
relies on long term host -pair keying or imposes a 

35 session-oriented protocol. In addition, setup is 
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needed to establish a shared key. 

The present invention provides a simple technique 
to secure datagram communication without the extra 
setup in establishing a secure session, wherein a seal 
5 is appended onto each individual datagram packet, as 
shown in FIG. 6. For example, seal 602 is appended 
onto datagram packet 6 01; seal 6 04 is appended onto 
datagram packet 603; and seal 606 is appended onto 
datagram packet 605. By allowing each datagram packet 

10 601, 603, 605 to have its own seal 602, 604, 606, 

respectively, the order in which the datagram packets 
are received becomes irrelevant because no handshake or 
synchronization between the sender and the receiver is 
required. Similarly, a lost datagram packet does not 

15 impact the communication or the encryption integrity 
for the rest of the packets because every packet has 
its own seal and encryption/decryption for each packet 
can be accomplished individually and independently from 
the other packets. Hence, a seal appended to each 

20 datagram packet effectively eliminates the need for a 
connection setup, e.g., synchronizing 
encryption/decryption keys. 

FIG. 7 illustrates a duplex transmission utilizing 
seals. In conventional cryptography, the exchange of 

25 keys between two communicating entities involves some 

form of handshake mechanism in which a shared symmetric 
key is exchanged. The handshake mechanism creates 
extra overhead which in turn incurs significant time 
penalties for time critical applications such as 

30 teleconferencing. FIG. 7 illustrates a data stream 700 
where a seal 704 is appended to the head of data 
section 702, sent from a first party. Another data 
stream 706 having a seal 710 appended to the head of 
data section 708 is sent from a second party. The 

35 appending of a seal to the head of a data section 
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allows full duplex communication without the initial 
exchange of keys, thus avoiding associated costs. 

When data section 702 with the appended seal 704 
is received at the second party, the second party sends 
5 the seal to the security server to be opened. The 
security server then returns a permit if the second 
party is an authorized client. The second party can 
then generate a decryption key from the permit and 
decrypt the received data 702. Similarly, when data 

10 section 708 with the appended seal 710 is received at 
the first party, the first party sends seal 710 to the 
security server to be opened. The security server 
returns a permit extracted from seal 710 if the first 
party is authorized. The first party then uses the 

15 returned permit to generate a decryption key which is 

then used to decrypt the received data section 708. No 
synchronization between the first party and the second 
party is required because the data from each party has 
its own seal. Furthermore, no handshake protocol is 

20 required since no key exchange is required between the 
first party and the second party. 

Although the invention has been described with 
reference to particular embodiments, the description is 
illustrative and not limiting. Various other 
25 adaptations and combinations of features of the 

embodiments disclosed are within the scope of the 
invention as defined by the following claims. 



-20- 



M-7190 US 
478096 v2 



CLAIMS 

I claim: 

1. A method for key management, comprising: 

generating a set of encrypted bits at a 
5 security server; 

transmitting said set of encrypted bits from 
said security server to an application server; 

broadcasting said set of encrypted bits from 
said application server to a plurality of 
10 recipients, said set of encrypted bits comprising 

information for generating a set of 
encryption/decryption bits; 

transmitting said set of encrypted bits from 
a first recipient to said security server; 

15 authenticating said first recipient at said 

security server; 

transmitting a first set of bits from said 
security server to said first recipient if said 
first recipient is authenticated, said first set 
20 of bits being a subset of said set of encrypted 

bits in decrypted form and comprising information 
for generating a set of encryption bits; 

generating said set of encryption bits at 
said first recipient from said first set of bits; 
25 encrypting a data stream at said first 

recipient using said set of encryption bits to 
form a first encrypted data stream; and 

broadcasting said first encrypted data stream 
from said first recipient with said set of 
30 encrypted bits to a plurality of receivers. 



2. The method of Claim 1, wherein said set of 
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encrypted bits further comprises information selected 
from the group consisting of a policy, a message 
digest, and a date and time stamp. 



5 3. The method of Claim 2, wherein said policy 

comprises information selected from the group 
consisting of security levels of said recipients and 
classification of said data stream. 



10 4. The method of Claim 1, wherein said 

authenticating comprises: 

establishing a private access line ("PAL") 
between said security server and said first 
recipient, comprising: 

15 transmitting an identification of said 

first recipient to said security server; 

decrypting said set of encrypted bits at 
said security server to obtain access 
information; and 
20 comparing said identification to said 

access information to establish 
authentication when said identification 
matches said access information. 



25 5. The method of Claim 1, further comprising: 

transmitting said set of encrypted bits from 
a first receiver to said security server; 

authenticating said first receiver at said 
security server; 
30 transmitting a second set of bits from said 

security server to said first receiver if said 
first receiver is authenticated, said second set 
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of bits being a subset of said set of encrypted 
bits in decrypted form and comprising information 
for generating a set of decryption bits; 

generating at said first receiver said set of 
5 decryption bits from said second set of bits; and 

decrypting said first encrypted data stream 
using said set of decryption bits at said first 
receiver . 



6. The method of Claim 1, wherein said 
broadcasting said first encrypted data stream further 
comprises : 

dividing said first encrypted data stream 
into a plurality of data sections; and 

attaching said set of encrypted bits to each 
of said data sections, each said data section 
having a corresponding offset value, said offset 
value is an offset between the starting address of 
said first encrypted data stream and the starting 
address of said data section. 



7. The method of Claim 1, wherein said 
application server comprises a memory for storing said 
set of encrypted bits and a corresponding set of bits 
25 containing said information for generating a set of 
encryption/decryption bits. 



8. The method of Claim 7, further comprising 
comparing said set of encrypted bits to a plurality of 
30 sets of encrypted bits in said memory. 



9. The method of Claim 8, further comprising 
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returning a set of bits corresponding to a stored set 
of encrypted bits from said memory if said set of 
encrypted bits matches said stored set of encrypted 
bits . 

5 

10. The method of Claim 8, wherein said set of 
encrypted bits fails to match any of said stored set of 
encrypted bits in said memory, further comprising: 

transmitting an identification of said first 
10 receiver to said security server; 

decrypting said set of encrypted bits at said 
security server to obtain access information; and 

comparing said identification of said 
receiver to said access information to establish 
15 authentication when said identification matches 

said access information. 

11. The method of Claim 10, further comprising 
storing said set of encrypted bits and said 

20 corresponding set of bits containing said information 
for generating a set of encrypt ion/decrypt ion bits in 
said memory subsequent to said authentication. 

12. The method of Claim 11, further comprising 
25 deleting a least recently used set of encrypted bits 

and its corresponding set of bits from said memory when 
said memory is full. 

13. The method of Claim 1, further comprising 
30 broadcasting said first encrypted data stream in 

datagram packets, wherein said set of encrypted bits is 
attached to each of said datagram packets. 



-24- 



M-7190 US 
478096 v2 



14. The method of Claim 1, further comprising: 

appending said set of encrypted bits to said 
first encrypted data stream; and 

5 transmitting a second encrypted data stream 

from said first receiver to said first recipient, 
wherein a second set of encrypted bits is appended 
to said second encrypted data stream. 



10 15 . A method for synchronizing keys for streaming 

media, comprising: 

dividing an encrypted data stream into a 
plurality of encrypted data sections; 

generating an offset value for each encrypted 
15 data sections, said offset value being an offset 

between the starting address of said encrypted 
data stream and the starting address of said 
encrypted data section; 

attaching a set of encrypted bits and said 
20 offset value to each of said encrypted data 

sections to form a data stream; and 

broadcasting said data stream. 



16. A method for opening a seal, wherein said 
25 seal comprises a set of encrypted bits comprising 
information for generating a set of 
encryption/decryption bits, comprising: 

providing a client having a memory for 
storing previously opened seals and their 
30 corresponding permits, each of said permits being 

a subset of a corresponding seal and containing 
information for generating said set of 
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encryption/decryption bits; 

transmitting said seal from a security server 
to said client; and 

comparing said seal to said previously opened 
5 seals in said memory. 

17. The method of Claim 16, further comprising 
returning a permit corresponding to a first previously 
opened seal from said memory if said seal matches said 

10 first previously opened seal. 

18. The method of Claim 16, further comprising: 

transmitting said seal and an identification 
from said client to said security server if said 
15 seal fails to match any of said previously opened 

seals in said memory; 

decrypting said seal at said security server 
to obtain access information; and 

comparing said identification with said 
20 access information to obtain authentication if 

said identification matches said access 
information . 

19. The method of Claim 18, further comprising 
25 storing said seal and its corresponding permit in said 

memory if said client is authenticated. 

20. The method of Claim 19, further comprising 
deleting a least recently used previously opened seal 

30 and its corresponding permit when said memory is full 
prior to said storing. 
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21. A method for key synchronization, comprising 
transmitting a plurality of datagram packets from a 
first party to a second party, each datagram packet 
5 having a seal attached, said seal being a set of 

encrypted bits comprising information for generating a 
set of encrypt ion/decrypt ion bits. 



22. A method for key exchange and synchronization 
10 over a duplex channel, comprising: 

transmitting a first encrypted data stream 
having a first seal appended to the head of said 
first encrypted data stream from a first party to 
a second party, said first seal being a first set 
15 of encrypted bits comprising information for 

generating a first set of encryption/decryption 
bits; and 

transmitting a second encrypted data stream 
having a second seal appended to the head of said 
20 second data stream from said second party to said 

first party, said second seal being a second set 
of encrypted bits comprising information for 
generating a second set of encryption/decryption 
bits . 



23. The method of Claim 22, further comprising: 

transmitting said first seal from said second 
party to a security server; 

authenticating said second party at said 
security server; and 

transmitting a first permit from said 
security server to said second party if said 
second party is authenticated, said first permit 
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being a subset of said first seal, in decrypted 
form, and containing information for 
encrypting/decrypting said first encrypted data 
stream. 

5 

24. The method of Claim 23, further comprising: 

generating a first set of decryption bits at 
said second party; and 

decrypting said first encrypted data stream 
10 at said second party using said first set of 

decryption bits. 

25. The method of Claim 24, further comprising: 

transmitting said second seal from said first 
15 party to said security server; 

authenticating said first party at said 
security server; and 

transmitting a second permit from said 
security server to said first party if said first 
20 party is authenticated, said second permit being a 

subset of said second seal, in decrypted form, and 
containing information for encrypting/decrypting 
said second encrypted data stream. 



25 26. The method of Claim 25, further comprising: 

generating a second set of decryption bits at 
said first party; and 

decrypting said second encrypted data stream 
at said first party using said second set of 
30 decryption bits. 
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NETWORK SECURITY ARCHITECTURE SYSTEM UTILIZING SEALS 
Daniel F. Zucker 

5 ABSTRACT 

An efficient multicast key management is achieved 
by using seals. A security server generates a seal. 
In one embodiment, the seal contains a key. In another 
embodiment, the seal contains information for 

10 generating a key. An application server requests the 
seal from the security server and broadcasts the seal 
to a plurality of recipients. A recipient wishing to 
encrypt or decrypt a data stream transmits the received 
seal to the security server to be opened. If the 

15 recipient is authorized, the security server transmits 
a permit to the authorized recipient . In one 
embodiment, the recipient generates a key from the 
permit. In another embodiment, the permit is the key. 
If the recipient is a sender, the recipient encrypts 

20 data using the key and broadcasts the same encrypted 
data stream to all receivers. If the recipient is a 
receiver, the recipient decrypts an encrypted data 
stream using the key. In one embodiment, a seal with a 
corresponding offset value is sent periodically in a 

25 data stream. In another embodiment, multiple instances 
of identical seals are opened only once. In yet 
another embodiment, a seal is appended to each datagram 
packet. In a further embodiment, a seal is appended to 
any data stream. 
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